概述

與大多數現代框架一樣，Microsoft的.Net（DotNet）框架通常可以防止記憶體溢出和程式碼控制（例如：堆疊溢出）模式攻擊。
但是，多年來，該框架的某些功能現在被認為是不安全的，或者不能提供開發人員認為可以提供的保護。 以下是使用.Net語言進行開發時應注意的一般最佳實踐。

不受信任的程式碼和資源

引用安全程式碼撰寫方針：
- 不要使用部分受信任的程式碼，程式碼存取安全性(Code Access Security, CAS)或AllowPartiallyTrustedCaller屬性。
- 問題：
CAS被認為是通過在程式碼的各個部分分配"信任級別"來在運行時載入不受信任的函式庫/程式碼的一種方式。
Microsoft現在建議不要使用CAS作為防止惡意程式碼的手段。
部分信任程式碼和AllowPartiallyTrustedCaller也有類似的問題，其中沒有提供任何有效的保護。
- 解決方案：
僅載入由受信任方簽名的程式碼和資源。
- 不要使用.NET Remoting或二進制格式化程式（用於物件序列化/反序列化）
- 問題：
自2012年以來存在.Net框架中的序列化漏洞(MS12-035），後來的揭露發現序列化中的主要漏洞，超出了該文章所發表的內容。
- 解決方案：
將DataContractSerialiazer用作序列化物件的一部分。
- 不要使用分佈式組件對像模型（DCOM）。
-問題：
DCOM通常是不安全的，並且存在不安全物件序列化的問題。
-解決方案：
完全不要使用它。
考慮本地服務的命名管道（可用的跨平台）。
如果可能，請避免使用類似HTTP/REST的終結點，因為它們可能難以防範瀏覽器攻擊
請參閱[CVE-2017-12939]。

處理用戶輸入

以下最佳做法在很大程度上與ASP.Net和.Net嵌入式瀏覽器支持有關：

• 伺服器回應中的任何用戶資料都在客戶端上伺服器站點的上下文中運行。
  如果您的Web伺服器接收用戶資料並將其插入返回的Web頁面中，則可能包含一個標記，並且好像從伺服器中運行一樣。
• 客戶端可以請求任何URL。
• 考慮棘手或無效的路徑：
  • ..\，路徑非常長。
  • 使用通配符（*）。
  • 令牌擴展（％token％）。
  • 具有特殊含義的奇怪路徑形式。
  • 備用文件系統流名稱，例如filename :: $ DATA。
  • 文件名的簡短版本，例如longfi〜1代表longfilename。
• Eval（userdata）可以執行任何操作。
• 注意不要延遲綁定到包含某些用戶資料的名稱。
• 如果要處理Web資料，請考慮允許的各種轉義形式，包括：
  • 十六進制轉義（％nn）。
  • Unicode轉義（％nnn）。
  • 超長的UTF-8轉義（％nn％nn）。
  • 兩次轉義（％nn變為％mmnn，其中％mm是'％'的轉義）。
• 注意可能具有多個規範格式的用戶名。例如，您經常可以使用"MYDOMAIN \ username"表單或"username@mydomain.example.com"表單。